Инструкция по обеспечению безопасной работы в домене ALD Pro: правила HBAC¶

Когда сотруднику выдают доменную учетную запись, у него появляется возможность зайти с ее помощью на любой хост в домене, включая сервера, что при неправильной настройке зон ответственности при администрировании к объектам файловой системы создает угрозу несанкционированного доступа к информации, хранящейся на этих компьютерах.

Для повышения безопасности работы в домене администраторам следует ограничить доступ к компьютерам, что можно сделать с помощью правил управления доступом к хостам (host-based access control, HBAC).

Что такое HBAC-правила¶

Правила HBAC создают дополнительный слой авторизации, позволяя разрешить определенным пользователям использовать указанные службы на конкретных хостах.

Правила являются разрешающими, для каждого из трех субъектов безопасности следует определить область одним из двух способов:

Любой субъект — правило будет распространяться на все субъекты и группы субъектов данного вида.
Указанные субъекты — правило будет распространяться только на указанный перечень субъектов и групп субъектов данного вида.

Что такое «пользователи» и «хосты» обычно вопросов не вызывает, но вот понятие «служб» требует отдельного пояснения.

Механизм работы HBAC-правил¶

Службами в контексте HBAC являются любые приложения, которые используют PAM-стек для авторизации пользователей, при этом не важно, являются ли эти приложения обычными исполняемыми файлами или работают в фоне.

Стек подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM) - это система библиотек, обеспечивающая унифицированный программный интерфейс (Application Programming Interface, API) для абстрагирования приложений (таких как login и sudo) от выполнения стандартных задач аутентификации, причем, настройки аутентификации администраторы могут задавать для каждого приложения индивидуально с помощью файлов из директории /etc/pam.d/\*

Библиотека PAM делит задачи аутентификации на четыре независимые группы управления, которые отвечают за различные аспекты пользовательских запросов:

account – группа модулей, которые отвечают за проверку аккаунта, не истек ли пароль, разрешен ли пользователю доступ к запрашиваемому сервису.
authentication – группа модулей, которые отвечают за получение учетных данных пользователя и выполнение аутентификации. Чаще всего они реализуют какой-то диалог с пользователем для получения данных, но также возможны и способы аутентификации с использованием аппаратных ключей, биометрических устройств и пользовательских сертификатов.
password – группа модулей, которые отвечают за проверку пароля на соответствие требованиям безопасности по длине, стойкость к перебору, наличию часто запрещенных слов.
session – группа модулей, которые отвечают за выполнение задач до и после предоставления услуги, например, запись событий в журналы, монтирование домашнего каталога.

За работу HBAC-правил отвечает модуль pam_sss.so:

../../../_images/instrukciya-po-pravilam-hbac_1.png — Механизм работы HBAC-правил 1¶

При подключении пользователя по SSH (1) служба обращается к PAM библиотеке, чтобы создать контекст безопасности для выполнения команд от его имени (2). При вызове функции pam_start служба передает библиотеке свой идентификатор (PAM service name), который представляет из себя обычную строку, например sshd. Идентификатор службы обычно совпадает с именем исполняемого файла, но это не обязательно. Некоторые приложения могут использовать несколько идентификаторов, например, утилита sudo использует дополнительный идентификатор «sudo-i», а модуль mod_authnz_pam веб-сервера Apache2 так вообще позволяет проверять доступ к каждому разделу сайта с помощью отдельного идентификатора. Обратите также внимание, что в разных дистрибутивах Linux одни и те же службы могут использовать разные идентификаторы, например, ssh и sshd.

Значение идентификатора службы определяет имя файла, откуда библиотека PAM будет брать настройки стека модулей (3), для службы sshd настройки будут браться из файла /etc/pam.d/sshd. В конфигурационных файлах PAM-стека перечисляются необходимые модули и параметры их вызова. Для того, чтобы упросить управление PAM-стеком, конфигурационные файлы допускают использование инструкций @include, которые позволяют включить содержимое других файлов.

Получив необходимые настройки, библиотека PAM выполняет проверки, используя указанные модули (4), причем, за работу HBAC-правил отвечает модуль pam_sss.so. Итоговый ответ библиотека передает приложению (5), которое, в свою очередь, использует эту информацию для организации взаимодействия с пользователем (6).

Модуль pam_sss.so является клиентской библиотекой службы sssd, основная задача которой заключается в получении информации от службы каталога и локальном кешировании данных для ускорения обработки запросов. Учитывая необходимость кеширования, архитектура службы предусматривает наличие серверной части (backend), собеседника (responder) и локального кеша между ними, см. рисунок 2.

../../../_images/instrukciya-po-pravilam-hbac_2.png — Архитектура службы SSSD¶

Для вступления в силу изменений в настройках HBAC-правил вы можете воспользоваться на целевой машине командами sss_cache -E или sssctl cache-remove, чтобы очистить локальный кеш службы sssd. Утилиты входят в состав пакета sssd-tools, который нужно устанавливать дополнительно.

Доступ для администраторов ко всем компьютерам в домене, ограничение правила allow_all¶

Правила HBAC являются «разрешающими», т. е. «по умолчанию» доступ к службам на доменных компьютерах запрещен, и его нужно открывать с помощью правил. Однако, при развертывании домена автоматически создается правило allow_all, которое разрешает доступ «всех ко всему», поэтому для управления авторизацией на уровне HBAC вам нужно сначала ограничить область применения этого правила, например, только группой администраторов.

Внести указанные настройки можно через веб-портал на странице Групповые политики → Политики доступа к узлу → allow_all → Пользователи

../../../_images/instrukciya-po-pravilam-hbac_3.png — Группа компьютера¶

или из командной строки:

ipa hbacrule-mod allow_all --usercat=''
ipa hbacrule-mod allow_all --desc='Разрешает администраторам доступ к любому хосту в домене'
ipa hbacrule-add-user allow_all --group admins
ipa hbacrule-show allow_all

где:

hbacrule-mod — команда, с помощью которой можно модифицировать настройки существующей группы;
allow_all — имя правила, которые мы хотим модифицировать;
usercat — ключ, который позволяет изменить категорию для области применения в части пользователей. Может принимать два возможных значения — ‘all’ и пустая строка ’’;
hbacrule-add-user — команда, с помощью которой можно расширить область применения правила в части пользователей;
allow_all — имя правила, которое мы хотим модифицировать;
group — ключ, который позволяет добавить группу пользователей в область применения HBAC-правила;
admins — имя группы, которая будет добавлена в область применения правила;
hbacrule-show — команда, с помощью которой можно получить информацию о существующем HBAC-правиле;
allow_all — имя правила, по которому мы хотим получить информацию.

Примечание

Если из-за неправильной настройки HBAC-правил доступ к хостам будет все же заблокирован, вы сможете подключиться к порталу управления с любого другого компьютера, который не находится в домене, чтобы исправить ошибку. Доступ к порталу управления не регулируется через механизм HBAC.

Доступ для сотрудников на рабочие станции, создание правила allow_computers¶

Если ограничить область действия правила allow_all группой администраторов, то для остальных сотрудников компании нужно будет создать правило allow_computers, которое предоставит им право входа на обычные компьютеры в домене.

Создадим это правило с использованием веб-интерфейса:

Создайте группу хостов computers. Откройте страницу Пользователи и компьютеры → Группы компьютеров и нажмите кнопку [+ Новая группа]. Введите имя группы, ее описание и нажмите кнопку [Сохранить].

../../../_images/instrukciya-po-pravilam-hbac_4.png — Компьютеры¶

На вкладке Компьютеры внесите рабочие станции в список участников группы.

../../../_images/instrukciya-po-pravilam-hbac_5.png — Политика доступа к узлу 1¶

Создайте HBAC-правило. Откройте страницу Групповые политики → Политики доступа к узлу → Правила HBAC и нажмите кнопку [+ Новое правило]. Введите имя правила allow_computers и сохраните его. Для созданного правила определите следующую область действия:

пользователи — любой пользователь;
хосты — указанные компьютеры и группы, группа computers;
службы — любая служба.

../../../_images/instrukciya-po-pravilam-hbac_6.png — Политика доступа к узлу 2¶

../../../_images/instrukciya-po-pravilam-hbac_7.png — Политика доступа к узлу 3¶

../../../_images/instrukciya-po-pravilam-hbac_8.png — Политика доступа к узлу 4¶

../../../_images/instrukciya-po-pravilam-hbac_9.png — Политика доступа к узлу 5¶

Сделаем то же самое из командной строки:

ipa hostgroup-add computers
ipa hostgroup-mod computers --desc='Группа, в которой будут все обычные компьютеры домена'
ipa hostgroup-add-member computers --hosts pc-1

ipa hbacrule-add allow_computers
ipa hbacrule-mod allow_computers --desc='Разрешает всем пользователям доступ к обычным компьютерам в домене'
ipa hbacrule-mod allow_computers --usercat=all
ipa hbacrule-mod allow_computers --servicecat=all
ipa hbacrule-add-host allow_computers --hostgroup computers

Гранулированный доступ к отдельным службам и отладка правил¶

Для тонкой настройки HBAC вам потребуется тщательно анализировать типовые сценарии работы пользователей в части используемых служб. Например, для подключения по RDP потребуются fly-wm и xrdp-sesman, см. Службы, необходимые для типовых сценариев работы.

Службы, необходимые для типовых сценариев работы¶
Сценарий работы пользователя	К каким идентификаторам служб следует предоставить доступ	Комментарий
Локальный вход в операционную систему	fly-dm, fly-wm	fly-dm - разрешает вход, fly-wm - нужен, чтобы можно было разблокировать экран
Удаленный доступ к менеджеру окон по протоколу RPD	xrdp-sesman, fly-wm	xrdp-sesman - разрешает вход по rdp, fly-wm - нужен, чтобы можно было разблокировать экран
Удаленное администрирование по SSH	sshd, sudo	sshd - разрешает подключение по ssh, sudo - разрешает повышать привилегии в соответствии с правилами SUDO

Внимание

При переходе с ранних версий ALD Pro до 2.5.0 в системе будет создана группа служб HBAC fly куда будут входить: fly-dm, fly-dm-greeter, fly-dm-np, fly-wm. Если группа fly уже существовала, в нее будут добавлены перечисленные службы.

После установки системы в домене уже есть список наиболее распространенных служб, но какие-то службы все равно потребуется добавить вручную. Сделать это можно будет через веб-интерфейс на странице Групповые политики → Политики доступа к узлу → Службы HBAC. Пример создания «xrdp-sessman».

../../../_images/instrukciya-po-pravilam-hbac_10.png — Политика доступа к узлу 6¶

То же самое можно сделать из командной строки:

ipa hbacsvc-add 'xrdp-sesman'
ipa hbacsvc-mod 'xrdp-sesman' --desc='Доступ по RDP'

Чтобы понять, к какой службе требуется предоставить доступ, выполните необходимое действие на целевой системе и посмотрите, какие сообщения об ошибках появятся в журнале авторизации auth.log:

# tail -f varlog/auth.log
...
Mar 15 15:25:22 client 4 sshd[30424]: pam_sss(sshd:account): Access denied for user ivanov: 6 (Permission denied)
...

Допустим, нам нужно предоставить возможность разработчикам из группы dev-users на своих компьютерах из группы dev-computers только входить в операционную систему, а далее уже расширять возможности при администрировании до root с помощью утилиты su. Создать соответствующее HBAC-правило можно как через портал управления ALD Pro, так и из командной строки.

С использованием веб-интерфейса делается это следующим образом:

Создайте HBAC-правило. Для этого откройте страницу Групповые политики → Политики доступа к узлу → Правила HBAC и нажмите кнопку [+ Новое правило].

Введите имя правила «allow_developers» и нажмите кнопку [Сохранить]. Пока вы не сохраните правило, остальные вкладки с настройками будут недоступны.

../../../_images/instrukciya-po-pravilam-hbac_11.png — Политика доступа к узлу 7¶

Настройте область применения правила в части пользователей, выберите категорию «Указанные пользователи и группы» и добавьте группу «dev-users». В части компьютеров добавьте группу «dev-computers». Не забудьте нажать кнопку [Сохранить] в правом верхнем углу прежде чем переходить к следующей вкладке.

../../../_images/instrukciya-po-pravilam-hbac_12.png — Политика доступа к узлу 8¶

../../../_images/instrukciya-po-pravilam-hbac_13.png — Политика доступа к узлу 9¶

Настройте область применения правила в части служб, добавьте «fly-dm», «su» и «su-l» (используется утилитой su при вызове с параметром «-», «-l» или «–login»).

../../../_images/instrukciya-po-pravilam-hbac_14.png — Политика доступа к узлу 10¶

Из командной строки такое правило можно создать следующим образом:

kinit admin
ipa hbacrule-add allow_developers
ipa hbacrule-mod allow_developers --desc='Доступ для разработчиков'
ipa hbacrule-add-user allow_developers --groups dev-users
ipa hbacrule-add-host allow_developers --hostgroups dev-computers
ipa hbacrule-add-service allow_developers --hbacsvcs fly-dm
ipa hbacrule-add-service allow_developers --hbacsvcs su
ipa hbacrule-add-service allow_developers --hbacsvcs su-l

где:

kinit admin — аутентификация в системе под учетной записью admin;
hbacrule-add — команда для создания HBAC-правила;
hbacrule-mod — команда для модификация правила, ключ desc позволяет задать описание;
команды hbacrule-add-user, hbacrule-add-host и hbacrule-add-service позволяют определить область применения правила;
ключ groups — позволяет указать группу пользователей;
ключ hostgroups — позволяет указать группу хостов;
ключ hbacsvcs — позволяет указать идентификатор PAM службы.

Следует напомнить, что сразу после создания правила оно может заработать на целевой машине не сразу из-за кеширования sssd.

Теперь, чтобы пользователь смог воспользоваться утилитой su на личном компьютере, вам нужно передать ему пароль от учетной записи root.

Скорее всего, у пользователя root нет пароля и в файле /etc/shadow- в том месте, где должен быть указан хэш пароля вы увидите восклицательный знак. Откройте терминал на целевой системе и установите пользователю root пароль следующим образом:

sudo -i
passwd root
Новый пароль : *****
Повторите ввод нового пароля : *****
passwd: пароль успешно обновлён

Теперь пользователь может проверить, что у него есть доступ к компьютеру через графику и он может с помощью команды su запустить bash от имени root.

Когда у вас в домене два-три правила, их довольно легко проверить напрямую подключаясь к целевым хостам под тестовыми учетными записями, но в реальной инфраструктуре потребуется управлять десятками правил, и упростить их отладку поможет команда ipa hbactest. Команду можно выполнить на контроллере домена и для любого сочетания пользователь-хост-сервис получить ответ, есть ли в домене правило, которое соответствует этим критериям.

Выполним проверку, сможет ли пользователь ivanov воспользоваться службой sshd при подключении к хосту client4 по протоколу ssh:

ipa hbactest --user=ivanov --host=client4 --service=sshd
--------------------------
Доступ предоставлен: False
--------------------------
Несоответствующие правила: 1
Несоответствующие правила: allow_systemd-user

Решение False означает, что пользователю будет отказано в доступе.

Выполним проверку конкретного правила allow_developers с помощью ключа –rules, сможет ли пользователь ivanov выполнить вход на компьютер client4, для чего ему нужна служба fly-dm:

ipa hbactest --user=ivanov --host=client4 --service=fly-dm --rules allow_developers
-------------------------
Доступ предоставлен: True
-------------------------
Соответствующие правила: allow_developers

Решение True означает, что пользователю будет предоставлен доступ в соответствии с правилом allow_developers, значит пользователь ivanov входит в группу пользователей dev-users, а хост client4 в группу хостов dev-computers.

Лучшие практики: ограничение доступа локальным пользователям¶

Вопрос управления локальными учетными записями на компьютерах домена является одним из важнейших аспектов безопасности, который требует повышенного внимания со стороны системных администраторов.

Есть разные подходы к организации управления учетными записями локальных администраторов в домене, например, вы можете их полностью отключить, организовать управление через скрипты групповых политик или даже разработать стороннее решение, реализующее функции, аналогичные программному продукту LAPS от Microsoft (Local admin password solution).

В рамках данной статьи рассмотрим самый простой из них — это полное блокирование локальных учетных записей. Для того, чтобы заблокировать локальную учетную запись «localadmin» после ввода компьютера в домен вам достаточно будет выполнить команду:

passwd -l localadmin

Теперь вы можете убедиться, что вход и доступ к системе с помощью этой учетной записи будет запрещен.

../../../_images/instrukciya-po-pravilam-hbac_15.png — Группа пользователей¶

Лучшие практики: создание HBAC-правил для структурных подразделений¶

Область применения HBAC-правил можно задать с помощью групп пользователей и групп хостов, но в некоторых случаях может быть удобнее использовать для этого структурные подразделения. В этом случае вы можете воспользоваться вспомогательными группами и правилами автоучастия (automember).

Привязка объектов к структурным подразделениям в ALD Pro осуществляется с помощью атрибута rbtadp, в котором хранится ссылка на целевое подразделение в формате полного уникального имени записи (Distinguished name, DN). Например, если у вас в корне домена есть структурное подразделение «Московский офис», то значение атрибута rbtadp всех его дочерних объектов будет содержать ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan. Если вам потребуется ограничить выборку только прямыми наследниками, вы можете поставить символ подстановки «^» в начало строки, что позволит вам исключить объекты из подразделений, расположенных ниже по иерархии организационной структуры.

Создадим группу пользователей и правило автоучастия из веб-интерфейса:

Создайте группу пользователей, для этого на странице Пользователи и компьютеры → Группы пользователей нажмите кнопку [+ Новая группа], введите название группы «moscow-office-employees», выберите подразделение «Московский офис» и нажмите кнопку [Сохранить].

../../../_images/instrukciya-po-pravilam-hbac_16.png — Добавление правила¶

Создайте правило автоучастия, для этого потребуется воспользоваться интерфейсом FreeIPA. Откройте страницу Идентификация → Автоучастник → Правила группы пользователей, нажмите кнопку [Добавить]. В диалоговом окне добавления правила выберите группу «moscow-office-employees» из списка и нажмите кнопку [Добавить и изменить].

../../../_images/instrukciya-po-pravilam-hbac_17.png — Правило группы пользователей¶

На странице редактирования правила добавьте включающий критерий отбора записей по атрибуту rbtadp и значению ou=Московский офис,ou=ald.company.lan, cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan.

Пересчет правил автоучастия происходит не мгновенно, но вы можете ускорить применение этих правил с помощью команды automember-rebuild:

ipa automember-rebuild --type=group

Если пользователи так и не появятся в списке участников группы, проверьте корректность фильтра. Обзор записей выполняется по полному вхождению, поэтому никаких лишних пробелов в середине строки быть не должно.

../../../_images/instrukciya-po-pravilam-hbac_18.png — Правило группы пользователей¶

То же самое вы можете сделать из командной строки:

Создайте группу пользователей «moscow-office-employees» в подразделении «Московский офис»:

ipa group-add moscow-office-employees
ipa group-mod moscow-office-employees setattr="rbtadp=ou=Московский офис,ou=ald.company.lan, cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan"
ipa group-mod moscow-office-employees --desc='Группа, в которой будут все сотрудники московского офиса'

Создайте правило автоучастия и определите критерий автоучастие:

ipa automember-add moscow-office-employees --type=group
ipa automember-mod moscow-office-employees --type=group --desc='Правило автоучастия для наполнения группы сотрудников московского офиса'
ipa automember-add-condition moscow-office-employees --type=group --key=rbtadp --inclusive-regex='ou=Московский офис,ou=ald.company.lan, cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan'

Принудительно обновите состав автоучастников (запускать команду нужно только 1 раз, в дальнейшем правила будут срабатывать автоматически при изменении подразделения объекта):

ipa automember-rebuild --type=group